Partie 1 : Introduction

1. Avant-propos

1.1. Sur ce document

1.1.1. A qui est destiné ce document?

Les étudiants qui découvrent le langage, mes collègues enseignants qui cherchent un document de support à leur cours et d’exercice accessible, et … moi-même (pour organiser mes notes diverses)!

1.1.2. A qui n’est-il pas destiné?

Si vous appartenez à l’une de ces catégories, ce livre n’est pas pour vous :

  • vous cherchez un livre de référence (pour cela, même s’il est en anglais, je conseille [FMS])

  • vous voulez vous perfectionner (ce livre n’est qu’une introduction)

  • vous souhaitez préparer la certification de l’OMG (mieux vaut vous plonger dans la spécification [SysML])

1.1.3. Historique

Ce document est la compilation de plusieurs années d’enseignement de SysML depuis 2007, que ce soit :

Vous trouverez en référence (cf. Bibiliographie) les ouvrages et autres documents utilisés.

Je tiens à remercier mes collègues qui m’ont aidé dans mon entreprise :

1.2. Sur l’auteur

  • Professeur à l’Univesité de Toulouse

  • Co-fondateur de l’association SysML-France en 2009

  • Membre du comité éditorial de la revue Software and System Modeling journal depuis sa création en 2002

  • Membre du Steering Committee de la conférence ACM/IEEE MODELS depuis 2008

  • Enseignant en modélisation depuis 1995

  • Chef du département informatique de l’IUT de Blagnac de 2009 à 2012

  • Co-responsable de l’axe Systèmes Ambiants de l’IRIT

  • Marié, une (merveilleuse) fille

1.3. Comment lire ce document?

1.3.1. Version électronique

Ce document a été réalisé de manière à être lu de préférence dans sa version électronique, ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.

Note

Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, mais n’hésitez pas à en consulter la version électronique!

1.3.2. Conventions typographiques

J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :

  • des mises en formes particulières (e.g., NomDeBloc pour un élément de modèle),

  • des références bibliographiques, présentées en fin de document (cf. Bibliographie),

  • tous les flottants (figures, tableaux) sont listés à la suite de la table des matière,

  • les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons volontairement ces termes (e.g., Requirements).

Les figures, sauf mention contraire, ont été réalisées avec l’outil TOPCASED en français. Le titre des figures indique (entre parenthèses) un R pour les figures issues de Rhapsody et un UK pour les figures en anglais. Les conventions (de nommage notamment) sont regroupées en section [conventions].

Important
Pourquoi parler de "document"?

Parce que j’ignore la version que vous êtes en train de lire. A partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc:

  • pour le web (Moodle) au format html

  • pour présentation (en amphi par exemple) au format slidy ou deck.js

  • pour impression au format pdf (bien que bien sûr nous vous recommandons l’achat du livre)

  • pour lire au format Kindle (bientôt!)

1.3.3. Utilisation et autres mentions légales

Dernière MAJ : 26/12/2012 - 00:52:45 CET
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham. La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert. Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons. Licence Creative  Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant ici.

1.4. Méthode pour cet ouvrage

Everything should be made as simple as possible, but not simpler.

— Albert Einstein

Mon approche pédagogique repose sur quelques principes, que j’ai essayé de mettre en oeuvre dans cet ouvrage :

La répétition

Par exemple certains diagrammes sont abordés plusieurs fois (comme le diagramme paramétrique). Le lecteur pourra avoir une impression de redite par moment. Sauf erreur de ma part (toujours possible!), c’est volontaire. En général les répétitions vont en niveau de précision, de détails et de complexité croissant. Ces répétitions sont limitées dans la version livre de cet ouvrage (car toute longueur inutile a un coût dans ce cas).

L’illustration

Dans la mesure du possible, j’essaye de donner des exemples aux principes énoncés. Vous trouverez donc plus d’exemples que de définitions.

Le référencement

Les définitions ou autres affirmations sont tirées d’ouvrages de référence généralement citées.

La "carte de base"

J’aime réaliser une "carte"
[voir aussi le concept de Mind Maps.]
qui sert à "placer" les différents concepts abordés. Il me semble que cela permet aux étudiants de raccrocher les nouveaux concepts aux précédents.

Aucune connaissance particulière d’UML n’est nécessaire, même si j’y fais référence à plusieurs endroits pour les étudiants qui connaissent cette notation (quasiment enseignée partout maintenant comme langage de modélisation). Il s’agit d’un parti pris prenant en compte plusieurs points :

  • La plupart des ingénieurs systèmes ne connaissent pas UML.

  • Les étudiants de STI2D ne connaissent pas UML et sont pourtant formés à SysML.

  • Ceux qui connaissent UML auront sûrement plaisir à retrouver les bases.

2. C’est quoi SysML?

Si vous ne deviez lire qu’un seul chapitre, voilà ce qu’il faudrait retenir.

2.1. Fiche d’identité

  • Date de naissance non officielle : 2001!

  • Première spécification adoptée à l’OMG : 19 septembre 2007

  • Version actuelle : 1.3 (12/06/2012)

  • Paternité : OMG/UML + INCOSE

  • Auteurs principaux :

    • Conrad Bock

    • Cris Kobryn

    • Sanford Friedenthal

2.2. SysML, c’est…

Un ensemble de 9 types de diagrammes
  • Diagrammes structuraux

    • Diagrammes de définition de blocs (bdd)

    • Diagrammes internes de blocs (ibd)

    • Diagrammes paramétriques (par)

    • Diagrammes de packages (pkg)

  • Diagrammes comportementaux

    • Diagrammes de séquence (seq)

    • Diagrammes d’activité (act)

    • Diagrammes de cas d’utilisation (uc)

    • Diagrammes d'états (st)

  • Diagramme d’exigence (req)

Un profil UML

C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base d’UML. Un exemple : le bloc qui n’est qu’une redéfinition de la classe.

Une notation

Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.

2.3. SysML, ce n’est pas…

Une méthode

En effet, contrairement à ce que beaucoup pensent en l’abordant, SysML ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.

Un outil

Nous verrons en effet que SysML ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.

Un raton laveur

C’est juste pour voir ceux qui suivent.

2.4. Références et liens utiles

Vous trouverez en fin d’ouvrage un ensemble de liens utiles (cf. [liens]) et de références (cf. bibliographie).

3. A propos du Bac STI2D

Si vous utilisez cet ouvrage dans le cadre du bac STI2Dindexterm:[STI2D] (Sciences et Technologies de l’Industrie et du Développement Durable) qui a introduit depuis 2011 la notation SysML au programme, nous donnons ici des conseils sur l’utilisation de ce cours
[Je remercie au passage les collègues de Lycée rencontrés dans le cadre de SysML-France pour nos fructueuses discussions à ce sujet.]
.

L’objectif en STI2Dindexterm:[STI2D] n’est pas de former des spécialistes de SysML mais de permettre à tous d’apprendre une notation pour la modélisation de système qui se veut universelle. Il ne faut donc pas viser la complétude ou même demander trop de détails. La logique de la démarche de modélisation et l’importance de la communication devront primer.

Note

A l’heure où nous écrivons ces lignes, il est également prévu de l’enseigner en classe prépa dès 2013.

3.1. Diagrammes retenus

Seul un sous-ensemble des diagrammes de SysML a été retenu. Les élèves et les enseignants du bac STI2Dindexterm:[STI2D] pourront trouver dans ce document des éléments utiles sur ces diagrammes :

  • diagramme des exigences (cf. [reqs])

  • diagramme des cas d’utilisation (cf. [reqs])

  • diagramme de séquences (cf. [reqs])

  • diagramme d'états (cf. [reqs])

  • diagramme de définition de blocs (cf. [reqs])

  • diagramme de blocs internes (cf. [reqs])

Ces 6 diagrammes servent trois objectifs principaux inscrits au programme :

  • Modélisation des exigences (cf. [reqs])

  • Modélisation structurelle (cf. [reqs])

  • Modélisation comportementale (cf. [reqs])

3.2. Pour aller plus loin

Un blog récent recense les supports en liens avec STI2Dindexterm:[STI2D] : http://www.scoop.it/t/formation-sysml-sti2d.

4. Un exemple fil rouge

L’exemple de système qui sera modélisé tout au long de ce livre en guise d’exemple est l’exemple d’un système de gestion et de supervision de crise. Les détails sont donnés en annexe (cf. Annexes).

Il existe un certain nombre d’autres exemple complets :

Partie 2 : Ingénierie système

1. Introduction

La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :

Table 1. La carte de base
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

1.1. Points de vue

Dans un axe horizontal, j’ai différencié quatre grands points de vue :

Requirements

Les exigences et leur prises en compte sont un éléments critique pour le succès du développement du système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de [reqs]) nous insisterons beaucoup sur cet aspect qui est souvent à l’origine de l’intérêt de SysML.

Structure

La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de SysML qui pose le moins de problème aux débutants.

Comportement

Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.

Transverse

Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence entre les phases de développement ou entre les points de vue.

1.2. Phase de développement

Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :

Organisation

Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.)

Analyse

Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.

Conception

Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)

Implémentation

Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).

2. Différence avec l’ingénierie logicielle

Enseignant en informatique, je me retrouve souvent à enseigner SysML à des informaticiens. D’où ce petit exposé sur mon opinion de la différence entre les deux "mondes".

2.1. Une ingénierie plus ancienne

Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Systèmeindexterm:[IS] arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.

2.2. Des systèmes plus complexes

On parle de système complexe lorsque l’on a affaire à :

  • un ensemble d'éléments humains et matériels en relation avec :

    • de nombreux éléments technologiques (Informatique, Hydraulique, Electronique, …)

    • intégrés pour fournir des services (finalité du système) en fonction de leur environnement

    • interagissant entre eux et avec leur environnement

Figure 1. Un système complexe

On parle aussi de Système de systèmes quand un système :

  • doit gérer les interactions entre ses parties (ou composantes)

  • assure un comportement prévu à l’avance

  • gère les comportements (de l’environnement) inatendus

Figure 2. Un système de système

2.3. Différents types d’analyse

Toute la question que l’Ingénierie Systèmeindexterm:[IS] cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible.

Des reqs au système
Figure 3. Des exigences au système

Pour cela l’Ingénierie Systèmeindexterm:[IS] est découpée en plusieurs analyses, chacune avec un but bien particulier :

Des reqs au système
Figure 4. Analyse Fonctionnelle et/ou Comportementale
Des reqs au système
Figure 5. Analyse Structurelle
Des reqs au système
Figure 6. Analyse de performance
Des reqs au système
Figure 7. Analyses spécifiques

Pour arriver à combler le gap entre le système à développer et ses spécifications.

Des reqs au système
Figure 8. Des exigences au système

3. Normes et standards

Il existe un grand nombre de standards en Ingénierie Systèmeindexterm:[IS]. Cette section fera (bientôt) une revue de ces différents standards et organismes et de leur utilisation (IEEE, EIA, ISO, certification, NASA, INCOSE, AFIS, …).

Enfin, citons un rapport de 2010, le Rapport Potier, qui présente l'état des logiciels embarqués et qui sera utiles à ceux qui s’intéressent aux verrous technologiques liés à ce domaine.

L’Ingénierie Systèmeindexterm:[IS] génère beaucoup de documentation. Les processus de certification (par exemple dans l’aéronautique) sont encore basés sur des documents textuels.

4. Des documents aux modèles

Vue la complexité grandissante des systèmes, petit à petit cette ingénierie tente de passer d’une ingénierie centrée documents à une ingénierie centrée modèles. D’où l’importance de se poser la question des notations et langages pour réaliser et communiquer avec ces modèles (cf. [Notation]).

5. Les exigences

L’ingénierie des exigences est d’une importance capitale en Ingénierie Systèmeindexterm:[IS]. Nous renvoyons pour l’instant le lecteur au cours de Master qui précède ce cours.

Figure 9. 300 corps de métiers sont parfois présents sur un chantier
Joke
Illustration: Humour (taken from here)

6. L’architecture du système

Liens avec AADL, …

7. Le comportement du système

Liens avec la V&V

8. Méthodes et démarches

SysML n’est pas une méthode. En effet aucune démarche n’est imposée pour l’utilisation des diagrammes, l’ordre logique dans lesquels il vaut mieux les réaliser, etc. La spécification ne porte que sur la notation elle-même. D’où le pluriel dans le titre de cette section : il existe presque autant de méthodes que d’entreprise développant des systèmes. Nous nous contenterons de donner ici quelques heuristiques (cf. Annexe Considérations méthodologiques pour la présentation de quelques méthodes bien identifiées) :

Heuristique : Approche itérative

Un diagramme ne doit pas être considéré comme définitif. Il peut être complété alors que l’on traite un autre aspect de la modélisation (exemple classique : ajout d’un nouveau bloc lors de la réalisation d’un diagramme de séquence). Quelque soit la démarche adoptée elle doit être itérative et permettre de revenir sur les premières étapes.

Heuristique : Niveau d’abstraction

Bien intégrer les niveaux d’abstraction dans votre démarche. SysML possède certaines constructions pour formaliser cet aspect (Packages par exemple). Nous matérialisons cet aspect par la partie verticale de la matrice (cf. [Matrice]).

Heuristique : Tous les diagrammes ne sont pas utiles

N’essayez pas de réaliser tous les diagrammes possibles pour votre système. Réalisez uniquement ceux qui sont utiles à votre cas particulier.

Partie 3 : La notation SysML

1. Pourquoi une nouvelle notation

A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.

The World of Mathematics (1956)
— Bertrand Russell

Il existe une notation qui se veut "unifiée" pour les modèles : UML. Néanmoins cette notation est peu adaptée pour l’Ingénierie Systèmeindexterm:[IS] :

  • UML 1.x était complètement inadaptée :

    • Principalement pour les systèmes d’information

    • Peu de liens entre les diagrammes

    • Peu de liens entre les modèles et les exigences

  • UML 2.x n’est pas beaucoup mieux si ce n’est :

    • Implication des ingénieurs systèmes pour sa définition

    • Introduction du diagramme de structure composite

En conclusion UML est une bonne base :

  • Standard De facto en génie logiciel

  • Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)

  • Stable et extensible (grâce notamment au mécanisme de profile)

  • Beaucoup d’outils disponibles

Mais…

  • Manque de certains concepts clés d’Ingénierie Systèmeindexterm:[IS]

  • Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de classe ou d'héritage par exemple)

  • Trop de diagrammes (13 sortes)

2. Introduction à SysML

2.1. Fiche d’identité

  • Date de naissance non officielle : 2001!

  • Première spécification adoptée à l’OMG : 19 septembre 2007

  • Version actuelle : 1.3 (12/06/2012)

  • Paternité : OMG/UML + INCOSE

  • Auteurs principaux :

    • Conrad Bock

    • Cris Kobryn

    • Sanford Friedenthal

2.2. Différence avec UML

images/diff.png
Figure 10. Liens entre UML et SysML

2.3. Qui est "derrière"?

Industrie

American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …

Vendeurs d’outils

Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …

Autres organisations

AP-233, INCOSE, Georgia Institute of Technology, AFIS, …

2.4. Organisation des différents diagrammes

images/Figure4-1.png
Figure 11. Les 9 diagrammes SysML et leur lien avec UML
images/Figure4-1-bis.png
Figure 12. Version abrégée des diagrammes

2.5. Différence entre modèle et dessin

SysML n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML. Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.

C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML
[Sauf bien sûr au brouillon ou sur un tableau, notamment quand on travaille en équipe.]
, mais d’utiliser des outils dédiés (cf. section [Outils]).

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :

Table 2. Organisation
Requirements, cf. [reqs] Structure, cf. [archi] Comportement, cf. [behavior] Transverse, cf. [transvers]

Organisation

pkg

pkg, bdd

pkg

Analyse, Conception, Implémentation
[En fonction du niveau de détail.]

req

bdd, ibd, seq, par

uc, seq, st, act

par

3. Outils SysML

Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :

Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.

Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d'éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.

Important Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation.

4. Principes de base

Abordons quelques principes généraux de SysML.

  • Chaque diagramme SysML représente un élément de modélisation

  • Chaque diagramme SysML doit être incluse dans un cadre (Diagram Frame)

  • L’entête du cadre, appelé cartouche, indique les informations sur le diagramme:

    • le type de diagramme (req, act, bdd, ibd, sd, etc.)

    • le type d'élément (package, block, activity, etc.)

    • le nom de l'élément

    • le nom du diagramme ou de la vue

Dans l’exemple ci-dessous, le diagramme "Context_Overview" est un Block Definition Diagram (type bdd) qui représente un package, nommé "Context".

images/pacemaker-context.png
Figure 13. Exemple de diagramme SysML

5. Organisation

Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

5.1. Fondements

On abordera :

  • Le Package Diagram

  • Les différent types de packages

  • Les organisations possibles

  • La notion de Namespaces

  • Les Dependencies

5.2. Le Package Diagram

  • Identique à UML, et classique pour les développeurs (java notamment)

  • Permet d’organiser les modèles en créant un espace de nommage (cf [namespace])

Les modèles peuvent être organisés selon toutes sortes de considération (cf. [organisation]). Le mécanisme qui permet de les organiser est le package (paquetage).

  • hiérarchie "système" (e.g., entreprise, système, composant)

  • types de diagrammes (e.g., besoins, structure, comportements)

  • par points de vue

  • etc.

5.3. Les différent types de packages

Il existe plusieurs types de package :

models

un package "top-level" dans une hiérarchie de package

packages

le type le plus classique : un ensemble d'éléments de modèles

model librairies

un package prévu pour être réutilisé (importé) par d’autres éléments

views

un package spécial pour représenter les points de vue

Note

Un point de vue (viewpoint) est utilisé pour matérialiser une perspective particulière de modélisation. Il possède des propriétés standardisés (concerns, language, purpose, etc.) et permettent d’indiquer qu’une vue (un packetage particulier, stéréotypé <<view>>) est conforme (dépendance <<conform>>) à un point de vue.

5.4. Les organisations possibles

Les modèles peuvent être organisés selon toutes sortes de considération :

  • par hiérarchie "système" (e.g., entreprise, système, composant, …)

  • par types de diagrammes (e.g., besoins, structure, comportements, …)

  • par cycle de vie (e.g., analyse, conception, …)

  • par équipes (e.g., architectes, [IPT], …)

  • par points de vue (e.g., sécurité, performance, …)

  • etc.

images/pkg-organisation2.png
Figure 14. Exemple d’organisation
images/pkg-organisation-modelview.png
Figure 15. Exemple d’organisation
images/pkg-organisation.png
Figure 16. Exemple d’organisation
images/pkg-topcased.png
Figure 17. Exemple d’organisation
Note
Organisation par défaut

L’outil TOPCASED propose, lors de la création d’un premier modèle, de créer une organisation "type" par défaut.

images/pkg-template.png images/pkg-topcased-default.png

5.5. La notion de Namespaces

Un package est un espace de nommage pour tous les éléments qu’il contient. Ainsi, dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.

Note
Définition : Namespace (OMG SysML v1.3, p. 23)

The package defines a namespace for the packageable elements.

Note

Dans les outils SysML, vous pouvez demander à voir les noms complets (Qualified names) des éléments, c’est à dire le nom de l'élément prefixé par son (ou ses) package(s) (e.g., Structure::Products::Clock).

5.6. Les dépendances

Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :

Dependency

une dépendance "générale", non précisée,
représentée par une simple flèche pointillée ----->

Use

l'élément "utilise" celui à l’autre bout de la flèche (un type par exemple),
représentée par le stéréotype <<use>>

Refine

l'élément est un raffinage (plus détaillé) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<refine>>

Realization

l'élément est une "réalisation" (implémentation) de celui à l’autre bout de la flèche,
représentée par le stéréotype <<realize>>

Allocation

l'élément (e.g., une activité ou un requirement) est "alloué" sur celui à l’autre bout de la flèche (un block la plupart du temps),
représentée par le stéréotype <<allocate>>

5.7. En résumé

SysML propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d’UML. Ces mécanismes seront plus faciles à comprendre au travers de leur utilisation concrète dans la suite.

Table 3. Organisation
Requirements Structure Comportement Transverse

Organisation

package

package

package

dependencies

Analyse

Conception

Implémentation

5.8. Questions de révision

  1. Quels sont les 5 types de dépendances entre packageable elements ?

  2. À quoi cela peut-il servir de définir les dépendances (donnez des exemples concrets) ?

6. Les exigences

Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

6.1. Fondements

On abordera :

  • L’organization des Requirements

  • Les Requirements properties

  • Les Requirements links

  • Les Requirements Diagrams

  • Les considérations sur la traçabilité

  • Annotations des Requirements

  • Les Use Case Diagrams (scénarios)

Note

L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation système. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de l’AFISindexterm:[AFIS] ([REQ2012]).

6.2. L’organisation des Requirements

6.2.1. Différents types d’organisation

Comme nous l’avons vu pour les packages, plusieurs types d’organisations sont possibles :

  • Par niveau d’abstraction

    • Besoins généraux (en lien avec les use cases par exemple)

    • Besoins techniques (en lien avec les éléments de conception)

  • Par point de vue

    • Besoins principaux (en lien avec les use cases)

    • Besoins spécifiques :

      • Fonctionnels

      • Marketing

      • Environnementaux

      • Business

  • etc.

6.2.2. Tableaux de Requirements

Les requirements sont généralement stockés dans des feuilles excel.

images/req-table.png
Figure 18. Exemples tableau d’exigences
images/req-modelio.png
Figure 19. Import Modelio de tableau d’exigences

6.3. Les Requirements properties

Il est possible d’indiquer un certain nombre de propriétés sur un requirement :

  • priority (high, low, …)

  • source (stakeolder, law, technical, …)

  • risk (high, low, …)

  • status (proposed, aproved, …)

  • verification method (analysis, tests, …)

Les principales relations entre requirement sont :

Containment

pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–)

Refinement

pour décrire un ajout de précision (<<refine>>)

Derivation

pour indiquer une différence de niveau d’abstraction (<<deriveReqt>>), par exemple entre un système et un de ses sous-systèmes

Note

Lorsqu’un cas d’utilisation possède plusieurs cas <<refine>> qui pointent vers lui, on considère que ces différents cas sont des options possibles de raffinement (cf. [conventions]).

images/req-exp1.png
Figure 20. Exemples de relations entre exigences

Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons dans la partie transverse.

images/topcased-req-connections.png
Figure 21. Relations liées au requirements dans TOPCASED

6.5. Les Requirements Diagrams

Quelques exemples de req tirés de http://www.uml-sysml.org/sysml :

images/hsuv-reqs1.png
Figure 22. Exemples de composition d’exigences
images/hsuv-reqs2.png
Figure 23. Exemples de dépendances entre exigences

6.6. Les considérations sur la traçabilité

Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases (en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci sera abordé dans la partie transverse.

Note

En général chaque requirement devrait être relié à au moins un use case (et vice-versa!).

6.7. Annotations des Requirements

Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).

images/hsuv-reqs2.png
Figure 24. Exemples de rationale et problem

6.8. Les Use Case Diagrams (scénarios)

Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.

images/req-uc-relation.png
Figure 25. Exemple de lien entre use case et requirements

Ce diagramme est exactement identique à celui d’UML.

images/UCGestionNotes.png
Figure 26. Exemple de diagrammes des cas d’utilisation
images/uc.png
Figure 27. Autre exemple de diagrammes des cas d’utilisation
Tip

Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs.

6.9. En résumé

Les exigences sont très importantes en ingénierie système, plus en tout cas qu’en ingénierie logiciel, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences. Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML.

Table 4. Déclinaison des Exigences
Requirements Structure Comportement Transverse

Organisation

⊕–, <<deriveReqt>>

Analyse

<<satisfy>>, <<refine>>

<<satisfy>> entre reqs et UC

<<refine>>

Conception

<<allocate>>

Implémentation

<<satisfy>>, <<verify>>

En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. [sysmod]).

Figure 28. Exemple de démarche (SYSMOD Zigzag pattern)

6.10. Questions de révision

  • Quelles sont les différences entre besoins et exigences ?

  • En quoi les cas d’utilisation sont-ils complémentaires des exigences?

    1. Quelle est la différence entre un package de type model et un package de type package?

7. L’architecture du système

Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

7.1. Fondements

On abordera :

  • l’organisation du système et des modèles

  • les Block Definition Diagrams

  • les Internal Block Diagrams

  • les Parametric Diagrams (pour les contraintes physiques)

  • les Sequence Diagrams (diagramme de séquence système)

7.2. Organisation du système et des modèles

En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous avons abordé cette organisation ici.

Pour l’organisation du système, on trouve le plus souvent :

  • un diagramme décrivant le contexte (le système dans son environnement), décrit dans un block definition diagram (cf. [contextebdd])

  • un diagramme décrivant les éléments internes principaux du système, décrit dans un internal block diagram

7.3. Block Definition Diagrams

7.3.1. Principes de base

Un bdd peut représenter :

  • un package

  • un bloc

  • un bloc de contrainte (constraint block)

Un diagramme de bloc décrit les relations entre les blocs (composition, généralisations, …). Ce diagramme utilise les mêmes éléments que le diagramme de classe UML.

images/pacemaker-context.png
Figure 29. bdd du système dans son environnement

Un bloc est constitué d’un certain nombre de compartiments (Compartments) :

Properties

Equivalent UML des propriétés (e.g., attributs)

Operations

Les méthodes supportées par les instances du bloc.

Constraints

Les contraintes

Allocations

Les allocations

Requirements

Les exigences liées à ce bloc.

User defined

On peut définir ses propres compartiments

images/constraints.png
Figure 30. Exemple de définition de contraintes

7.3.2. Propriétés

On peut différencier 3 types de propriétés d’un bloc :

values

Des caractéristiques (quantifiables)

parts

Les éléments qui composent le bloc (cf. [ibd])

references

Les éléments auquel le bloc a accès (via des associations ou des agrégations)

Note

Les values sont ce qui se rapproche le plus des attributs de classes UML.

7.3.3. Value Types

Pour associer un type aux valeurs, SysML propose de définir des Value Types.

images/valueType.png
Figure 31. Définition de Value Types.

7.3.4. Associations entre blocs

Il existe deux types de relations entre blocs :

  • l’association (y compris l’agrégation et la composition)

  • la généralisation/spécialisation

Ces deux types de relations, bien connues en UML, permettent de matérialiser les liens qui existent entre les éléments du système. Avant d’aborder les associations, il est important de différencier la description d'éléments structurels sous la forme d’un bloc (au travers d’un bdd par exemple) et ces éléments pris individuellement. Ces derniers sont des instances individuelles du même bloc. Cette notion, très présente dans les approches orientées objets est souvent plus ardue à appréhender pour les ingénieurs systèmes. Il faut bien comprendre que la modélisation d’un bloc consiste à représenter l’ensemble des éléments qui caractérisent tout une série d’objets (des moteurs, des pompes, des données, etc.). Il serait fastidieux de les représenter tous (individuellement), et c’est donc leur "signature" que l’on représente. C’est pour cela qu’un bloc n’est pas un élément physique, mais simplement sa représentation, tandis qu’une instance de ce bloc représentera elle cet élément physique. C’est le cas notamment des participants d’un diagramme de séquence ou encore des parties d’un composé, qui sont des instances et non des blocs.

Association

Une association est un ensemble de liens permanents existant entre les instances de deux ou plusieurs blocs. On dira qu’une association lie plusieurs blocs ou que les blocs participent à l’association.

Une association possède plusieurs propriétés :

Dimension d’une association

Nombre de blocs mis en jeu par l’association
(binaire : 2, ternaire : 3, n-aire : n)

Note
Exemple d’association binaire

Soient les bloc Fournisseurs et Produits. On veut indiquer quels sont les produits susceptibles d’être fournis par chaque fournisseur et quels sont les fournisseurs susceptibles de fournir chaque produit.

/Users/bruel/dev/asciidoc/ACSI/images/prod-fourn.png

Nom d’une association

Afin de clarifier les informations, il est important de nommer les associations.
Il existe trois façons de nommer une association :

  • un verbe à l’infinitif (e.g., Fournir)

  • un verbe conjugué avec un sens de lecture : Fournit > ou < Est fourni par

  • un rôle (placé à une extrémité de l’association)

Cardinalité

Indique à combien d’instances minimum et maximum du bloc d’en face est lié toute instance du bloc de départ. Elle est représentée par un couple (M..N).

Note

Attention, dans une cardinalité M..N, M doit toujours être inférieur ou égal à N. Exemple : 3..10.

Vers le code : que signifie vraiment une association?

En terme de logiciel, une association représente une contrainte sur la suite du développement : que ce soit un code (en langage orienté objet la plupart du temps) ou une base de donnée.

Pour reprendre l’exemple précédent, cela signifie concrètement au niveau d’un code par exemple que depuis une variable Produits on doit être capable d’accéder à une variable (correspondante) de type tableau (ou liste, ou …) de Fournisseurs.

Ce qui peut donner en java :

public class Produits
{
//Produits Attributes
private String idPro;
private String designation;
private float poids;

//Produits Associations
private List<Fournisseurs> fournisseurs;
...

En terme d’ingénierie système, on utilisera plutôt des associations spécifiques (l’agrégation et la composition).

Figure 32. Deux façon de représenter une propriété de type B

En terme d’Ingénierie Systèmeindexterm:[IS], une composition indique que l'élément est une partie intégrante (on parle de part) du tout (un composant, comme le moteur d’une voiture par exemple) tandis q’une agrégation indique que l'élément est une partie "externe" (on parle de reference) comme la batterie d’un portable.

Note

Un moyen simple en terme logiciel de déterminer si une association A→B est une association dirigée (navigable dans un sens), une agrégation ou une composition est de raisonner en terme d’implémentation :

  • c’est une agrégation si b est initialisé dans le constructeur de A ;

  • c’est une composition si il est aussi détruit dans le destructeur de A ;

  • c’est une association dirigée simple si aucun des deux cas précédent ne s’applique.

Généralisation/spécialisation

Lorsque plusieurs blocs ont des caractéristiques en communs (propriétés, associations, comportement), il peut être utile de "factoriser" ces éléments en un bloc dont les autres vont "hériter". Quand on réalise ces liens hiérarchiques (on utilise souvent le terme "est un") en partant des blocs différents pour établir un nouveau bloc contenant les points communs on parle de généralisation. À l’inverse, quand on constate qu’un bloc possède réellement plusieurs déclinaisons différentes et que l’on créé alors des blocs spécifiques, on parle alors de spécialisation.

images/genspec.png
Figure 33. Exemple de lien de généralisation/spécialisation

On retrouve cette association entre blocs, mais aussi entre acteurs, cas d’utilisation, etc.

7.4. Internal Block Diagrams

Un ibd décrit la structure interne d’un bloc sous forme de :

parts

Les parties qui constituent le système (ses sous-systèmes)

ports

Elément d’interaction avec un bloc

connecteurs

Liens entre ports

7.4.1. Parts

Les parties sont représentés par les éléments au bout d’une composition dans un bdd. Elles sont créés à la création du bloc qui les contient et sont détruites avec lui s’il est détruit (dépendance de vie).

Warning

Il ne s’agit pas de redessiner le BDD. Les parts sont des instances et non des classes (au sens objet).
Cela ne pose aucun problème à un ingénieur système, mais ça peut en poser à un ingénieur logiciel.

On représente les parts comme des bloc en traits pleins et les references comme des blocs en trait pointillés.

images/parts.png
Figure 34. Exemple de Parts
images/parts2.png
Figure 35. Autre exemple de Parts

7.4.2. Ports

Les ports :

  • préservent l’encapsulation du bloc

  • matérialise le fait que les interactions avec l’extérieur (via un port) sont transmise à une partie (via un connecteur)

  • les ports connectés doivent correspondre (kind, type, direction, etc.)

Note

Les ports définissent les points d’interaction offerts («provided») et requis («required») entre les blocs.
Les connecteurs peuvent traverser les "frontières" sans exiger de ports à chaque hiérarchie.

images/ports-flots.png
Figure 36. Exemples de flots
images/flots.png
Figure 37. Exemples de flots multi-physique entre ports

Les ports peuvent être de nature classique (comme en UML) et représenter la fourniture ou le besoin de services. Ils peuvent aussi être de nature "flux physique".

Les Flux peuvent être :

  • atomiques (un seul flux),

  • composites (agrégation de flux de natures différentes).

Note

Un flow port atomique ne spécifie qu’un seul type de flux en entrée ou en sortie (ou les deux), la direction étant simplement indiquée par une flèche à l’intérieur du carré représentant le port. Il peut être typé par un bloc ou un Value Type représentant le type d’élément pouvant circuler en entrée ou en sortie du port.

7.5. Parametric Diagrams

Ce diagramme utilise 3 concepts clefs :

  • Constraints (un type de bloc)

  • Parametric diagram (un type d'ibd)

  • Value binding

7.5.1. Contraintes

C’est un bloc particulier :

  • avec un stéréotype ≪constraint≫ (au lieu de bloc)

  • des paramètres en guise d’attributs

  • des relations liant (contraignant) ces paramètres

images/constraints.png
Figure 38. Exemple de contraintes

7.5.2. Diagramme paramétrique

C’est une forme particulière de Internal Block Definition

images/param.png
Figure 39. Exemple de diagramme paramétrique

7.5.3. Value Binding

Une fois les contraintes exprimées, il faut lier les paramètres (formels) à des valeurs (paramètre réel). C’est l’objet des Value Binding.

Pour assigner des valeurs spécifiques, on utilise des Block Configurations;

Figure 40. Exemple de bloc de configuration

7.6. Diagrammes de séquence système

Les diagrammes de séquence système (DSS) sont des Sequence Diagrams UML classiques où seul le système est représenté comme une boîte noire en interaction avec son environnement (les utilisateurs généralement).

Il permet de décrire les scénarios des cas d’utilisation sans entrer dans les détails. Il convient donc mieux à l’ingénierie système qu’un diagramme de séquence classique (cf. section sur les [seq]).

images/dss.png
Figure 41. Exemples de DSS

7.7. En résumé

En résumé, il existe plusieurs diagrammes permettant d’exprimer la structure du système à concevoir. En fonction du niveau de détail nécessaire on peut voir les sous-systèmes comme des boîtes noires (des blocs) ou comme des boîtes blanches (grâce à l'ibd correspondant).

Table 5. Place des aspects structurels
Requirements Structure Comportement Transverse

Organisation

package

Analyse

bdd par

Conception

bdd par ibd dss

Implémentation

bdd par ibd dss

7.8. Questions de révision

  1. Quelles sont les différences entre une association dirigée (), une composition (losange noir) et l’agrégation (losange blanc) ?

  2. Puisqu’un bdd me donne souvent la liste des sous-systèmes (liens de composition), pourquoi ai-je besoin d’un ibd ?

8. Le comportement du système

Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

8.1. Fondements

On abordera :

  • les Use Case Diagrams (scénarios)

  • les Sequence Diagrams

  • les State Machines

  • les Activity Diagrams

8.2. Use Case Diagrams

Les éléments de base :

Acteurs

les principaux acteurs (leur rôle) qui participent (on parle parfois d’acteurs principaux) ou qui bénéficient (on parle alors d’acteurs secondaires) du système.

Cas d’utilisation

représente un ensemble d’actions réalisées par le système intéressant pour au moins un acteur

Association

participation d’un acteur à un cas d’utilisation.

Sujet

le domaine étudié (qui peut être une partie seulement de tout le système, pas forcément modélisé dans son ensemble)

Tip

Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs.

8.3. Le Diagramme des Cas d’Utilisation

Le Diagramme des Cas d’Utilisation est un diagramme UML permettant de représenter :

  • les UC (Use Case ou Cas d’Utilisation)

  • les acteurs (principaux et secondaires)

  • les relations

    • entre acteurs et Use Case

    • entre Use Cases

Note

On notera simplement uc pour signifier "diagramme des UC"

8.3.1. Cas d’Utilisation (Use Case)

Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.

Exemple de cas d’utilisation (UML)

Retrait par carte bancaire

Scénario principal

L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.

Scénario alternatif n°1

Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.

Exemple de codification de l’UC

UC01 ou RetraitCB (pour Retrait par carte bleue)

Précisions

Un cas d’utilisation peut être précisé par :

  • une description textuelle

  • un ou des diagrammes UML (séquence, activité)

Note

Dans les outils, cette "précision" se manifeste par le fait que l’on "attache" généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un Use Case → nouveau seq).

8.3.2. Acteur

Un acteur peut être une personne, un ensemble de personnes, un logiciel, un processus qui interagit avec un ou plusieurs UC.

On peut trouver plusieurs types d’acteurs :

  • extérieurs au système (cf. actor [ucdiag])

    • les acteurs principaux

    • les acteurs secondaires

  • exemples de types d’acteurs prédéfinis dans UML :

    • <<utility>>

    • <<process>>

    • <<thread>>

Note

On peut utiliser des liens de généralisation/spécialisation entre acteurs pour représenter les possibilités pour le spécialisé d’avoir les mêmes prérogatives (notamment en terme d’utilisation du système) que le généralisé.

8.3.3. Relations entre acteurs et Use Case

En général, une simple association relie acteurs et Use Case. On peut également orienter ces associations en plaçant une direction (flèche vide) au bout de l’association.

8.3.4. Relations entre Use Case

Après avoir lister les cas d’utilisation, il est utile de les organiser et de montrer les relations entre eux. Plusieurs relations sont possibles :

Extension (<<extend>>)

Indique que le Use Case source est éventuellement exécutée en complément du Use Case destination (cas particulier, erreur…). Le point précis où l’extension peut se produire est appelé extension point (surtout utile quand il existe plusieurs extensions pour un même cas)

Inclusion (<<include>>)

Indique que le Use Case est inclus obligatoirement dans un autre Use Case (notion de sous-fonction par exemple)

Généralisation

Relation entre un Use Case général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute (différents modes d’utilisation d’un système par exemple, ou encore différents acteurs impliqués)

Figure 42. Notation dans le diagramme d’UC
Tip

On n’utilise généralement <<include>> que dans le cas où le sous-cas d’utilisation est inclut dans plusieurs UC. Si ce n’est pas le cas, il est généralement englobé dans l’UC.

8.3.5. Pour construire un UC (de manière générale)

  1. identifier les acteurs

  2. identifier les cas d’utilisation

  3. structurer en packages

  4. finaliser les diagrammes de cas d’utilisation (ajouter les relations)

Note

Certains méthodologistes (comme T. Wielkins) préconisent de ne pas utiliser les acteurs et les cas d’utilisation (cf. son blog)

8.3.6. Exemples complets (UML)

Service comptable
Exemple de Diagramme d'UC
Figure 43. Exemple de diagramme d’UC
Gestion des notes
Exemple de Diagramme d'UC
Figure 44. Autre exemple de diagramme d’UC

8.4. Sequence Diagrams

8.4.1. Généralités

Il permet de :

  • modéliser les interactions entre blocs

  • séquencer ces interactions dans le temps

  • représenter les échanges de messages

  • spécifier les scénarios des cas d'études

Les éléments qui composent ce diagramme sont :

Participants

les éléments en interaction (des blocs généralement)

Lignes de vie

des lignes verticales qui permettent d’indiquer un départ ou une arrivée d’interaction

Barres d’activation

pour matérialiser quand l'élément est actif

Messages

ce qui "circule" d’un élément à l’autre (signal, appel de méthode, …)

Diagramme de séquence
Figure 45. Exemple de diagramme de séquence (1)
Eléments de notation
Figure 46. Exemple de diagramme de séquence (2)
Warning

Les participants (et leur ligne de vie) représentent des instances de blocs (souvent "anonymes").

8.4.2. Exemple

Exemple de diagramme de séquence
Figure 47. Exemple de diagramme de séquence (3)

8.4.3. Notions avancées

On peut également représenter des instructions itératives et conditionnelles au travers de cadres d’interaction :

  • loop (boucle)

  • alt (alternative)

  • opt (optionel)

  • par (parallèle)

  • region (région critique - un seul thread à la fois)

Un algorithme
Figure 48. Exemple d' algorithme…
Sa modélisation
Figure 49. Et le diagramme correpondant

8.4.4. Exemple de conceptions

Conception 'centralisée'
Figure 50. Conception "centralisée"
Conception 'objet'
Figure 51. Conception "objet"
Note

On utilise le diagramme de séquence pour représenter des algorithmes et des séquencements temporels. Lorsque le comportement se rapproche plus d’un flot, on utilise le diagramme d’activité (cf. section sur le [act]).

8.4.5. Lien entre UC, DSS et DS

La décomposition hiérarchique permet une description "TOP-DOWN" du système à réaliser.

On fait un Diagramme de Séquence Système pour chaque cas d’utilisation (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.

Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les blocs composant le système (issus du bdd) collaborent pour réaliser le traitement demandé.

Diagramme d'UC
Figure 52. Diagramme d’UC
Le DSS correspondant
Figure 53. Le DSS correspondant
Le DS correspondant
Figure 54. Le DS correspondant

8.5. Diagramme d'états

SysML a repris le concept, déjà connu en UML, de machine à états (State Machines). Ce diagramme représente les différents états possibles d’un bloc particulier, et comment ce bloc réagit à des événements en fonction de son état courant (en passant éventuellement dans un nouvel état). Cette réaction (nommée transition) possède un événement déclencheur, une condition (garde), un effet et un état cible.

Le diagramme d’états comprend également deux pseudo-états :

  • l’état initial du diagramme d’états correspond à la création d’une instance ;

  • l’état final du diagramme d’états correspond à la destruction de l’instance.

Un diagramme d'état
Figure 55. Un exemple de diagramme d'état (R,UK)

Lorsqu’un état nécessite lui-même plus de détails, on créé un état composite (aussi appelé super-état) qui est lui-même une machine à état. On peut ainsi factoriser des transitions déclenchées par le même événement (et amenant vers le même état cible), tout en spécifiant des transitions particulières entre les sous-états. Il est également possible d’attacher un diagramme d'état (composite) à un état pour garder une représentation hiérarchique.

Un diagramme d'état peut représenter des régions concurrentes (dont les activités peuvent évoluer en parallèle), graphiquement représentées par des zones séparées par des traits pointillés. Chaque région contient ses propres états et transitions.

Il existe encore d’autres concepts avancés que nous ne présenterons pas dans cette introduction car ils sont beaucoup moins utilisés (entry, exit, transition interne, etc.).

8.6. Diagrammes d’activité

Les diagrammes d’activité (Activity Diagrams) est utilisé pour représenter les flots de données et de contrôle entre les actions. Il est utilisé pour raffiner en général un cas d’utilisation. Il est utilisé pour l’expression de la logique de contrôle et d’entrées/sorties. Le diagramme d’activité sert non seulement à préciser la séquence d’actions à réaliser, mais aussi ce qui est produit, consommé ou transformé au cours de l’exécution de cette activité.

images/act-pcmk1.png
Figure 56. Exemple de diagramme d’activité (tiré de [SeeBook2012])

Les éléments de base du diagramme d’activité sont :

  • les actions,

  • les flots de contrôle entre actions,

  • les décisions (branchements conditionnels),

  • un début et une ou plusieurs fins possibles.

8.7. Actions

Les actions sont les unités fondamentales pour spécifier les comportements en SysML. Une action représente un traitement ou une transformation. Les actions sont contenues dans les activités, qui leur servent alors de contexte.

8.8. Flots

Un flot de contrôle permet le contrôle de l’exécution des noeuds d’activités. Les flots de contrôle sont des flèches reliant deux noeuds (actions, décisions, etc.).

Le diagramme d’activité permet également d’utiliser des flots d’objets (reliant une action et un objet consommé ou produit). Les object flow, associés aux broches d’entrée/sortie (input/output pin) permettent alors de décrire les transformations sur les objets manipulés.

Un flot continu
Figure 57. Un exemple de flot continu (UK)

Pour permettre la modélisation des flots continus, SysML ajoute à UML la possibilité de caractériser la nature du débit qui circule sur le flot : continu (par exemple, courant électrique, fluide, etc.) ou discret (par exemple, évenements, requêtes, etc.). On utilise pour cela des stéréotypes : <<continuous>> et <<discrete>>.

Note

Par défaut, un flot est supposé discret.

8.9. Décision

Une décision est un noeud de contrôle représentant un choix dynamique entre plusieurs conditions (mutuellement exclusives). Elle est représentée par un losange qui possède un arc entrant et plusieurs arcs sortants. Il existe plusieurs noeuds de contrôle (cf. Fig. [Control]) :

fork

Un fork est un noeud de contrôle représentant un débranchement parallèle. Il est représenté par une barre (horizontale ou verticale) qui possède un arc entrant et plusieurs arcs sortants. Le fork duplique le "jeton" entrant sur chaque flot sortant. Les jetons sur les arcs sortants sont indépendants et concurrents.

join

Un join est un noeud de contrôle structuré représentant une synchronisation entre actions (rendez-vous). Il est représenté par une barre (horizontale ou verticale) qui possède un arc sortant et plusieurs arcs entrants. Le join ne produit son jeton de sortie que lorsqu’un jeton est disponible sur chaque flot entrant (d’où la synchronisation).

flow final

Contrairement à la fin d’activité qui est globale à l’activité, la fin de flot est locale au flot concerné et n’a pas d’effet sur l’activité englobante.

merge

La fusion est l’inverse de la décision : le même symbole du losange, mais cette fois-ci avec plusieurs flots entrants et un seul sortant.

images/flow-ctrl.png
Figure 58. Les différents contrôles de flow SysML

8.10. Réutilisation

Les activités peuvent être réutilisées à travers des actions d’appel (callBehaviorAction). L’action d’appel est représentée graphiquement par une fourche à droite de la boîte d’action, ainsi que par la chaîne : nom d’action : nom d’activité. SysML propose encore bien d’autres concepts et notations, comme la région interruptible, la région d’expansion ou encore les flots de type stream qui sortent du cadre de ce livre d’intriduction.

images/act-call.png
Figure 59. Exemple de callBehaviorAction (UK)

8.11. En résumé

Il existe de nombreux diagrammes pour exprimer les comportements. Ces modèles sont importants dans la mesure où ils peuvent servir à valider le futur système vis-à-vis de ces comportements exprimés. Ils ne sont donc véritablement utiles que lorsqu’ils sont couplés à des outils de simulation ou d’analyse (cf. [Analyse]).

Table 6. Place du Comportement
Requirements Structure Comportement Transverse

Organisation

package

Analyse

uc ds

Conception

dss ds act

Implémentation

sm

8.12. Questions de révision

  1. Comment, pour exprimer un comportement, savoir si j’ai besoin d’un diagramme de séquence plutôt qu’un diagramme d’activité ou encore d’une machine à état ?

8.13. Exercices

8.13.1. Diagramme des cas d’utilisation

Placez dans un diagrammes des cas d’utilisation les différents acteurs et cas correspondant à l'étude de cas suivante (en indiquant les relations) :

Pour faciliter sa gestion, un entrepôt de stockage envisage de concevoir un système permettant d’allouer automatiquement un emplacement de stockage pour chaque produit du chargement des camions qui convoient le stock à entreposer. Lors de l’arrivée d’un camion, un employé doit saisir dans le système les caractéristiques de chaque article ; le système produit alors une liste où figure un emplacement pour chaque article. Lors du chargement d’un camion les caractéristiques des articles à charger dans un camion sont saisies par un employé afin d’indiquer au système de libérer les emplacements correspondant.

9. Les aspects transversaux

Table 7. Aspects transversaux
Requirements Structure Comportement Transverse

Organisation

Analyse

Conception

Implémentation

9.1. Fondements

On abordera ici les aspects transversaux comme :

  • la traçabilité des exigences

  • les mécanismes d’allocation

  • le diagramme paramétrique

9.2. Traçabilité des exigences

Nous avons vu déjà un certain nombre de mécanismes SysML qui permettent de tracer les exigences. Nous les regroupons ici dans une matrice spécifique (qui se lit dans le sens des relations, par exemple un élément de structure comme un bloc <<satisfy>> une exigence).

Table 8. Traçabilité
Requirements Structure Comportement

Requirements

<<deriveRqt>>, <<refine>>, <<copy>>

Structure

<<allocate>>, <<satisfy>>

<<allocate>>

Comportement

<<refine>>

Comme indiqué dans le tableau ci-dessus, en général, le lien de raffinement est utilisé entre une exigence et un élément comportemental (état, activité, uc, etc.) tandis que l’allocation concerne principalement les éléments de structures.

XXX Mettre un exemple avec tous ces liens.

9.3. Mécanismes d’allocation

Un mécanisme nouveau en SysML et important pour l’Ingénierie Systèmeindexterm:[IS] est le mécanisme d'allocation. Il permet de préciser quel élément conceptuel (comme un comportement ou une activité) est alloué sur quel élément physique.

Il est possible d’exprimer cette allocation de plusieurs manières.

Parler du <<AllocatedTo>>, compartiments des blocs et autres annotations. Parler des zones d’allocation dans les machines à états où les diagrammes d’activités par exemple. Parler des <<allocate>>.

9.4. Diagramme paramétrique

C’est une forme particulière de Internal Block Definition. Nous avons abordé cela dans la section [param].

images/param.png
Figure 60. Exemple de diagramme paramétrique
Note

Certaines approchent utilisent des feuilles excel pour traduire les diagrammes paramétriques et contrôler l’impact des changements de valeurs de tel ou tel paramètre.

9.5. En résumé

En résumé l’expression du comportement du système en SysML est très similaire à ce qui est fait dans UML. On retrouve néanmoins le renforcement des liens entre éléments de modèles par les dépendances précises et les allocations. Un autre élément de renforcement entre éléments de modèles concerne le fait qu’un diagramme comportemental (comme une machine à état) est attachée à un élément bien précis (par exemple un bloc). Ces liens apparaissent entre blocs et machines à état, entre cas d’utilisation et diagrammes de séquence ou d’activité, etc.

9.6. Questions de révision

  1. Quelles sont les différences entre <<satisfy>> et <<allocate>> ?

  2. Pourquoi est-il important de relier un use case à au moins un requirement ?

  3. L’inverse est-il aussi important ?

Partie 4 : Modéliser un système en SysML

1. Une démarche parmi d’autres

Nous allons aborder le développement complet de notre exemple fil rouge en suivant une démarche classique et simple (utilisée par exemple dans [SeeBook2012], où proche de la démarche globale enseignée dans nos cous de DUT Informatique, ou encore proche des documents de référence en la matière [HAS2012], [KAP2007],[FIO2012]) :

  1. Spécification du système

  2. Conception du système

  3. Traçabilité et Allocations

  4. Modèle de test

Nous partirons du modèle des exigences produit initialement. Mais avant tout, parlons outils.

1.1. Environnement de développement

Nous sommes des défenseurs des principes [DRY] et [TDD]. Nous allons donc réaliser nos diagrammes dans un outil et non "à la main" (de simples dessins). Nous choisissons ici l’outil TOPCASED pour des raisons que nous expliquerons ailleurs. La version utilisée pour réaliser les exemples de cette section est la version 5.2.

Un outil SysML seul ne suffit pas (cf. Outillage). Il faut penser à la documentation (cf. Génération de doc).

Outillage autour de SysML
Figure 61. Outillage autour de SysML

1.1.1. Outils

Il existe de nombreux outils SysML. Nous renvoyons le lecteur sur le site de SysML-France pour des informations sur les dernières versions des outils.

1.1.2. Génération de documentation

La plupart des outils permettent de générer de la documentation. Pour les outils basés eclipse comme TOPCASED, il est possible d’utiliser le plug-in GenDoc2.

Figure 62. Génération de documentation à partir de TOPCASED (1)
Figure 63. Génération de documentation à partir de TOPCASED (1)

Les outils commerciaux comme Rhapsody permettent de générer de nombreux formats.

Figure 64. Génération de documentation à partir de Rhapsody

1.1.3. Animation de modèles et simulation

Fortement liée aux outils, la possibilité d’animer les modèles ou encore d’effectuer des simulations est une exigence de plus en plus forte des ingénieurs systèmes.

Il existe de nombreuses possibilités. Citons par exemple :

Génération de code VHDL

L’outil RTaW propose, via génération de code VHDL de simuler les modèles. Voir une démonstration ici.

Simulation en Rhapsody

L’outil Rhapsody possède une interface très pratique pour faire du prototypage rapide.

Voir mon tutoriel (en anglais) disponible ici.

Animation de modèles en Artisan

L’outil Artisan permet également de faire de l’animation de modèles.

Figure 65. Animation Artisan

1.2. Spécification du système

Il s’agit ici de décrire le contexte et d’identifier les principaux cas d’utilisation du système.

1.3. Conception du système

Chaque cas d’utilisation sera précisé (seq et act). Les données métier seront alors identifiées pour construire le modèle d’architecture logique (bdd et ibd) complété par la description des comportements complexes (st). Enfin le modèle d’architecture physique permettra de déterminer les aspects déploiement et constructions physiques d'équipements/

1.4. Traçabilité et Allocations

Afin de consolider les différents modèles, les liens de traçabilité qui n’auront pas été déjà décrit
[Il est recommandé de ne pas attendre pour matérialiser ces liens, mais de les exprimés dès que rencontrés dans telle ou telle modélisation.]
seront rajoutés en insistant sur les liens :

  • de satisfaction des exigences par les éléments de l’architecture,

  • d’allocation des éléments du modèle fonctionnel vers les éléments logiques,

  • d’allocation des éléments logiques vers les éléments de l’architecture physique.

1.5. Modèle de test

Nous insistons dans l’ensemble de nos formations sur les approches test-driven, alors nous montrons dans cette section comment participer à la qualité du développement d’un système en formalisant (par exemple avec des diagrammes de séquence de scénarios à éviter) les test et les jeux de test.

2. Recettes et bonnes pratiques

La plupart des ouvrages sur un langage enseignent les éléments de ce langage, comme nous l’avons fait à la partie précédente. Nous allons ici partir du principe inverse : comment modéliser tel ou tel partie ou vue de mon système avec SysML. Un peu à la manière des ouvrages du type Cookbook, nous allons donner une liste non exhaustives de recettes. Les choix des éléments de modélisation sont arbitraires ou tirés de discussions (comme ce sera mentionné si c’est le cas).

2.1. Architecture

Recette : Je souhaite modéliser mon système dans son environnement

C’est conseillé. Un block System permet de raccrocher tous les éléments qui le composent à un même niveau.

Dans l’exemple ci-dessous le système (le bloc Pacemaker) est lui-même un simple composant d’un élément de plus haut niveau : le contexte du système (le bloc Context) qui relie alors le système à son environnement.

Voir aussi la section [contexte].

Le contexte du Pacemaker
Figure 66. Le contexte du Pacemaker ([SeeBook2012])

2.2. Comportement

Recette : Je souhaite modéliser les différents modes (nominal, alternatifs)

Un diagramme d'état peu modéliser les différents modes et les événements qui produisent les changements de mode.

Partie 5 : Pour aller plus loin

1. Considérations méthodologiques

Exemples de démarche autour de SysML, lien avec la section Méthodes.

2. Analyses et simulation

To be completed…

3. Exercices de révision

Reprendre ici les questions des chapitres (à organiser en fichiers!).

3.1. Quizz

3.1.1. Sujet

Un quizz en ligne est disponible ici (me contacter pour le mot de passe).

En voici une capture d'écran :

Crosword
Figure 67. Exemple de QCM sur SysML

3.1.2. Corrigé

L’ensemble des questions du quizz a été généré à partir de ce fichier quizz (qui contient les réponses).

3.2. Mots croisés

3.2.1. Sujet

Voici un petit exercice (en anglais pour l’instant, désolé) pour changer :

Crosword
Figure 68. Mots-croisés sur SysML
Vertical (across)
  • 2. outside-inside connection

  • 4. the full name of a model element is also a … name

  • 6. the black diamond in SysML

  • 9. History is one of them

  • 10. what a block can do

  • 13. between states

  • 14. a supporter of SysML

Horizontal (down)
  • 1. used to describe a flow of actions

  • 3. message represented by a regular (unfilled) arrow

  • 5. each use case is advised to be linked to at least one of them

  • 7. they are handled in SysML by Packages

  • 8. communication entity in a seq

  • 11. a supporter of SysML

  • 12. number of diagrams in SysML

Annexes

1. Liens utiles

2. Conventions

Il existe un certain nombre de conventions complémentaires aux règles de la spécification elle-même. Nous ne les donnons ici qu'à titre indicatif. Il est important pour une organisation qui souhaite utiliser SysML comme notation pour ses modèles de se mettre d’accord sur ce type de convention. En voici quelques-unes :

  • Convention pour les noms :

    • de blocs commencent par une majuscule (origine : UML)

    • de cas d’utilisation (qui représentent une action) doivent être un verbe à l’infinitif (origine : UML)

    • d’activité (qui représentent une action) doivent être un verbe à l’infinitif (origine : UML)

    • d’attributs commencent par une minuscule et ne sont pas au pluriel (origine : UML)

  • Convention pour les requirements :

  • Dépendances

    • En général un cas d’utilisation qui n’est inclus (<<include>>) que dans un seul autre cas est fusionné dans ce dernier

    • Lorsqu’un cas d’utilisation possède plusieurs cas <<refine>> qui pointent vers lui, on considère que ces différents cas sont des options possibles de raffinement (cf. [conventions]).

Note

Pour les origines UML de certaines conventions, cf. [Styles].

3. Le temps et sa prise en compte dans les modèles

Il existe plusieurs façon de représenter les informations temporelles.

SysML permet par exemple d’ajouter des contraintes temporelles sur le diagramme de séquence. Il existe deux types de contraintes :

  • la contrainte de durée, qui permet d’indiquer une contrainte sur la durée exacte, la durée minimum ou la durée maximum entre deux événements ;

  • la contrainte de temps, qui permet de positionner des étiquettes associées à des instants dans le diagramme au niveau de certains messages et d’ainsi contraindre leur relation.

images/temps.png
Figure 69. Exemple de contrainte temporelle (tirée de [SysML])

Néanmoins, pour une prise en compte industriel des contraintes temporelles, il conviendra d’utiliser le profil dédié à ces aspects : le profil MARTE.

4. FAQ

Cette Frequently Asked Question a été construite par expérience, en regroupant les questions des étudiants durant mes différentes interventions. J’ai aussi ajouté des questions souvent rencontrées dans les journées organisées par SysML-France.

Note Voir aussi cette FAQ très bien faite.

Cette FAQ peut servir de base à la révision d’examens (cf. aussi [Exos]).

Peut-on avoir un requirement contenu plusieurs fois ?

Non. Le lien de containment est en fait une action qui place le "contenu" dans le "contenant". Dans TOPCASED, le diagramme laisse les liens précédents à l'écran, mais dans le modèle, c’est bien le dernier containment réalisé qui est pris en compte. Dans la figure ci-dessous le lien A-C a été "dessiné" après celui B-C.

exercices/topcased-containment-1.png
Figure 70. Exemple de divergence modèle/diagramme (diagramme)
exercices/topcased-containment-2.png
Figure 71. Exemple de divergence modèle/diagramme (modèle)
Note

Ce "bug" provient du fait que le lien de containment n’est pas un lien de dépendance, mais plutôt une représentation graphique de la contenance.

Comment alors peut-on "partager" un requirement ?

(En lien avec la question précédente)

L’organisation SysML des requirements est en fait un arbre. Pour réaliser ce "partage" certains utilisent un lien <<copy>> pour créer plusieurs copies d’un même requirement. Personnellement je n’aime pas cette solution.

exercices/topcased-containment-3.png
Figure 72. Exemple de partage de requirement

Peut-on avoir un lien <<satisfy>> entre exigences?

Techniquement oui (<<satisfy>> étant dérivé de <<dependency>>), mais ça n’a pas beaucoup de sens que de dire qu’un besoin est satisfait par un autre. Il s’agit le plus souvent d’un lien <<deriveReqt>>.

Note

Certaines méthodes utilise ce lien pour par exemple exprimer qu’une exigence cliente est satisfaite par une exigence système (comme la méthode [Harmony]).

Quelle est la différence entre <<deriveReqt>> et <<refine>> ?

La norme n’impose pas de sémantique précise à <<deriveReqt>>. Il y a généralement deux interprétations.

  1. Un usage classique est de l’utiliser pour ajouter des exigences plus détaillés déduites à partir d’autres exigences. Un exemple issue de la norme est une exigence de puissance moteur déduite (deriveReqt) depuis l’exigence sur l’accélération d’un véhicule.

  2. Une vision plus stricte, aussi illustré par l’exemple précédent, est que l’exigence dérivée est une condition nécessaire (un pré-requis) à l’exigence cible.

Autre exemple respectant 1 mais pas 2 : "Le véhicule doit posséder 4 roues." est dérivé de "Le véhicule doit se déplacer sur route." En effet, un aéroglisseur répondrait aussi l’exigence initiale et n’a pourtant pas de roues.

Quant au <<refine>> il est utilisé pour indiquer qu’un élément de modèle (qui peut être lui-même un requirement) est un raffinement (au sens niveaux d’abstraction, du plus abstrait au plus concret) d’un requirement. Par exemple, un use case ou un diagramme d’activité peut être un raffinement d’une exigence fonctionnelle (textuelle par exemple).

A quoi sert le lien <<trace>> ?

Il est utilisé pour indiquer que l’on souhaite conserver un lien de traçabilité entre les éléments (par exemple entre un élément de modélisation et un document). Il est recommandé d’utilisé une de ces versions plus précises (<<deriveReqt>> ou <<satisfy>> par exemple).

Quelle est la version courante de la spécification et comment l’obtenir?

Quels en sont les changements notables depuis la dernière version ?

(en lien avec la question précédente)

Les changements notables par rapport à la 1.2 concernent :

  • synchronisation avec les changements d’UML 2.3

  • le métamodèle de Conjugate ports et sa notation

  • le nommage des activity regions "interruptible"

  • inclusion de UML instance

  • inclusion des structured activity nodes d’UML

  • inclusion des multiple item flow d’UML

  • améliorations du support à Unit et QuantityKind pour les value types, et ajout d’un modèle (non normatif) pour définir les systèmes d’unités et de quantités.

Note

SysML v1.3 Revision Task Force dirigée par Roger Burkhart et Rick Steiner améliore de manière régulière la spécification en fonction des retours des utilisateurs.

Divers

Quelques autres questions que je laisse à votre sagacité :

  • Pourquoi les ingénieurs systèmes auraient-ils besoin d’un n-ième langage de modéliation ?

  • Quelles sont les relations entre “open source SysML” et “OMG SysML” ?

  • Quelle est la feuille de route pour SysML 2.0?

  • Quelles sont les relations entre UML et SysML? Peut-on les utiliser ensemble?

  • Peut-on "customizer" SysML?

  • Quel langage est le plus facile à apprendre, SysML ou UML?

5. Bibliographie

  • [FIO2012] Fiorèse S., Meinadier J., Découvrir et comprendre l’ingénierie système, AFIS 2012.

  • [FMS] Friedenthal…

  • [HAS2012] Haskins C., SE Handbook Working Group, INCOSE Systems Engineering Handbook: Version 3.2.2, International Council on Systems Engineering, 2012.

  • [KAP2007] Kapurch S., NASA Systems Engineering Handbook, 2007 (pdf).

  • [] ENSI Bourges/PRiSM.

  • [REQ2012] Guide Bonnes Pratiques en Ingénierie des Exigences, AFIS 2012.

  • [Roques2010] Pascal Roques. SysML par l’exemple - Un langage de modélisation pour systèmes complexes. Eyrolles. a acheter ici.

  • [SeeBook2012] Kordon et al. To be published. XXX

  • [Sommerville1997] Ian Sommerville, Pete Sawyer. Requirements Engineering: A Good Practice Guide. Wiley, 1997.

  • [SysML] OMG. Systems modeling language version 1.3. Technical report, 2012.

  • [taoup] Eric Steven Raymond. The Art of Unix Programming. Addison-Wesley. ISBN 0-13-142901-9.

  • [Walsh1999] Norman Walsh & Leonard Muellner. DocBook - The Definitive Guide. O’Reilly & Associates. 1999. ISBN 1-56592-580-7.

  • [Harmony] Bruce Powel Douglass. Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development. Addison-Wesley Professional, 2009. ISBN-10: 0-321-54549-4

  • [Styles] Scott W. Ambler. The Elements of UML 2.0 Style. Cambridge University Press, 2005. ISBN: 0-521-61678-6

6. Glossaire

Acronymes SysML

bdd

Raccourcis pour Block Definition Diagram dans une cartouche SysML

ds

Diagramme de Séquence (cartouche seq)

dss

Diagramme de Séquence Système (un ds où seul le système dans sa globalité est représenté)

ibd

Raccourcis pour Internal Block Diagram dans une cartouche SysML

seq

Raccourcis pour diagramme de séquence dans une cartouche SysML

Définitions générales

Note
Ressources

Les définitions ci-dessous sont regroupées à titre indicatif. Je vous invite à consulter les sources suivantes :

DRY

Don’t Repeat Yourself : Un bon principe qui veut qu’on évite de répéter des tâches manuelles (comme les tests) en utilisant plutôt des scripts et des programmes.

INCOSE

International Council on Systems Engineering : une organisation fondée en 1990 pour faire avancer les technologies d’Ingénierie Systèmeindexterm:[IS].

IPT

Integrated Product Team : une équipe classique en développement système.

OMG

Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).

TDD

Test Driven Development : Développements dirigés par les tests. On écrit les tests avant d'écrire le code. On travaille son code tant que les tests ne passent pas.

TRL

Technology Readiness Level : système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d'évaluer le niveau de maturité d’une technologie (cf. Wikipedia).

SysML

System Modeling Language ™ : le langage de modélisation de systèmes maintenu par l’OMG.

Dernière MAJ : 26/12/2012 - 00:52:45 CET
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham. La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert. Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons. Licence Creative  Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.